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© Apparatus and method for verifying compatibility of system components. 



© Each component (101) of a plurality of interact- 
ing system components is associated with a version 
identifier (102). The version identifier (102) is stored 
in a location accessible by the other components. 
Each component independently reads the version 
identifier of every other component with which it 
must interact, and compares this value to an inter- 
nally stored compatibility record (103) to determine 
whether the other component satisfies requirements 
for compatibility with the verifying component. Any 
component which detects an incompatibility signals 
an error to the system. In the preferred embodiment, 
the components are software modules, and the ver- 
sion identifier and compatibility record contain in- 
teger values. The compatibility record value repre- 
sents the minimum level required of the module 
being verified for compatibility with the verifying 
module. Compatibility verification is accomplished 
by comparing the actual level of the module being 
verified with the minimum level in the compatibility 
record. If the actual level is equal to or greater than 
the minimum level, the module being verified satis- 
fies compatibility requirements. 
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The present invention relates to data process- 
ing component usage, and in particular to verifying 
that two or more interacting components of a digital 
data system are compatible with eacn other. 

A modern computer system typically com- 
prises a variety of different interconnected proces- 
sors, each executing its own software. A single 
central processing unit (CPU) is typically the basic 
workhorse of the computer, but other processors 
control disk storage devices, printers, terminals, 
communications with other computers, etc. Even 
more remote and primitive processors may control 
other functions, such as monitoring sensors, input 
keypads, etc. In addition, multiple computer sys- 
tems may be connected to a network, whereby 
they may communicate with each other. 

In such a system, it is common for multiple 
system components to interact with each other. For 
example, interacting software modules may be run- 
ning in separate processors or in a single proces- 
sor. Processors which control peripheral functions, 
such as disk storage controllers, rr jst be able to 
transmit data to and from the syst m CPU using 
some defined protocol. Therefore th software run- 
ning in the peripheral processor mi A be compati- 
ble with the operating system softw. re of the main 
system. Similarly, multiple software modules may 
be sharing the CPU and certain sy* 3m resources. 
These modules may interact, for ex; nple, by shar- 
ing memory, and must be compati le in the way 
they access and alter the shared dai . 

System components, and partic jlarly software 
modules, are subject to frequent rev.sion, either to 
correct known errors in the component or to en- 
hance its function. As a result of hese frequent 
revisions, many versions of a component may ex- 
ist, each with slightly different capabilities. Some 
versions of a component may th erefore be in- 
compatible with some versions of an interacting 
module. For example, if^software mc dules A and B 
share a data structure, the addition )f a new func- 
tion to module A may require a m w field in the 
data structure, and consequently aquire a new 
version of module B to support this r jw field. 

Where multiple software moduli s are licensed 
from a single source and as a sing! ; package, the 
software developers can solve the problem of in- 
compatible revision levels by guaranteeing that all 
modules shipped as part of the package are com- 
patible with each other. A number of techniques 
exist in the art for tracking changes to software in 
the development environment and t. sting interact- 
ing modules before shipment to thu customer to 
verify compatibility. However, wher j one module 
must interact with another from a d ferent source, 
or that may have been acquired l orn the same 
source at a different time, the proi lem becomes 
more complex. 



One approach to the problem is to allow the 
modules to execute and let standard system error 
recovery procedures detect incompatibility. While 
this may work in some cases, there is no guarantee 

5 that the system error recovery procedures will al- 
ways detect incompatibility. For example, the in- 
compatibility may be one which will corrupt data 
without generating an error condition. Another ap- 
proach is to require that all modules be at the 

w same level. While this guarantees module compati- 
bility, it is unduly restrictive. Some modules may 
be compatible with each other even though not at 
the same level. This problem is particularly acute 
in the case of components which are not easily 

75 replaced not easily replaced, as for example, when 
software for a peripheral controller is stored in a 
read-only memory. There exists a need for a gen- 
eral method of verifying compatibility of system 
components, which will not prevent compatible 

20 components of differing version levels from inter- 
acting. 

It is therefore an object of the present invention 
to provide an enhanced method and apparatus for 
verifying compatibility of a plurality of interacting 

25 system components. 

It is therefore an object of the present invention 
to provide an enhanced method and apparatus for 
verifying compatibility of a plurality of interacting 
software modules. 

30 Another object of this invention to provide a 
more reliable method and apparatus for detecting 
component incompatibility. 

Another object of this invention is to reduce the 
instances of reported incompatibility among inter- 
as acting components which are in fact compatible. 

Another object of this invention is to reduce the 
need for replacing interacting components which 
are in fact compatible. 

Another object of this invention is to reduce the 

40 cost of operating a computer system with multiple 
interacting system components. 

Each component of a plurality of interacting 
system components is associated with a version 
identifier, which in the preferred embodiment is an 

45 integer value. The version identifier is stored in a 
location accessible by the other system compo- 
nents. Each component independently reads the 
version identifier of every other component with 
which it must interact, and compares this value to 

so an internally stored compatibility record to deter- 
mine whether the other component satisfies re- 
quirements for compatibility with the verifying com- 
ponent. Any component which detects an incom- 
patibility signals an error to the system. It is possi- 

55 ble under this arrangement for component A to 
satisfy compatibility criteria required by component 
B, but not vice versa. 

In the preferred embodiment, the components 
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are software modules. It is assumed that a software 
module at any arbitrary level will satisfy all com- 
patibility requirements that are satisfied by each 
lower level of that same module. The compatibility 
record contains an integer representing the mini- 
mum level required of the module being verified for 
compatibility with the verifying module. Compatibil- 
ity verification is accomplished by comparing the 
actual level of the module being verified with the 
minimum level in the compatibility record. If the 
actual level is equal to or greater than the minimum 
level, the module being verified satisfies compati- 
bility requirements. 

Fig. 1 shows a typical system component in its 
environment according to the preferred embodi- 
ment of this invention; 

Fig. 2 is a block diagram of the steps required 
in each component to verify compatibility with 
interacting components, according to the pre- 
ferred embodiment; 

Fig. 3 shows an example of a computer system 
using this invention. 

Figure 1 shows a typical system component 
101 in its environment according to the preferred 
embodiment of the present invention. In this pre- 
ferred embodiment, the component is a software 
module 101 comprising a block of machine instruc- 
tions and data stored in a memory 110. Module 
101 executes in a programmable processor 111 
coupled to the memory. Module 101 interacts with 
one or more other software modules to perform 
some desired function. Module 101 contains ver- 
sion identifier 102, which in the preferred embodi- 
ment is an integer value. In the preferred embodi- 
ment, the version identifier is stored in a pre- 
defined memory location in the module, from which 
it can be read by other modules. Module 101 also 
contains compatibility check routine 103, which 
comprises component version table 104 and a se- 
ries of instructions to jicgess the version identifiers 
of interacting modules and compare these to val- 
ues in table 104. Component version table contains 
one or more entries 105, each entry corresponding 
to a software module with which module 101 must 
interact. Each entry 105 comprises component 
class field 106 which identifies the interacting soft- 
ware module, and compatible version field 107 
identifying the compatible versions of the interact- 
ing module. In the preferred embodiment, compati- 
ble version field 107 is an integer representing the 
minimum version level of the interacting module 
which satisfies requirements for compatibility with 
software module 101. 

In the preferred embodiment, compatibility 
check routine 103 directly accesses the version 
identifier in each interacting module by accessing a 
memory location which is a fixed offset from the 
beginning of the interacting module. However, any 
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number of alternative methods could be employed. 
For example, in one alternate embodiment, a sepa- 
rate software module, callable by each of the inter- 
acting modules, could contain a fetch version func- 

5 tion which accesses the location of the version 
identifiers. A software module would access the 
version identifier of another software module by 
issuing a call to the fetch version function, passing 
it the component name of the software module for 

10 which the version identifier is desired. In another 
alternative embodiment, an operating system reads 
all module version identifiers and creates a table of 
such identifiers in a location accessible to all mod- 
ules. In another alternative embodiment, the mod- 

75 ule performing compatibility checking interrogates 
the interacting module for its version identifier via a 
pre-defined interface. The present invention only 
requires that each module in a set of interacting 
modules have means for accessing the version 

20 identifiers of the other modules in the set. 

Figure 2 shows the steps required in each 
module of a set of interacting modules to verify 
compatibility of the set. In accordance with this 
invention, each module of the set must indepen- 

25 dently verify that each other module with which it 
interacts satisfies minimum requirements for com- 
patibility with the module. Each module of the 
interacting set first accesses the version identifier 
of an interacting component (step 201), and ac- 

30 cesses the minimum version level required for 
compatibility with the component from its compo- 
nent version table 104 (step 202). If the actual level 
represented by the version identifier is less than 
the minimum level from the table (step 203), the 

35 interacting component being verified is added to an 
error list (step 204). If there are more interacting 
components to check, the process repeats (step 
205), until all interacting components have been 
checked. When all components have been 

40 checked, if any components are in the error list 
(not compatible with the component performing 
compatibility checking) (step 206), an error con- 
dition is signalled (step 207). The response of the 
system to such an error condition would be depen- 

45 dent on the application, but it would generally 
mean that the modules would not be permitted to 
execute, because results may be unpredictable. 

In the preferred embodiment, it is assumed 
that a software module at any arbitrary lever will 

so include the capabilities and functions of each lower 
level of that same module that are required for 
compatibility with other modules. Thus, for pur- 
poses of compatibility, a higher level of a module 
being verified will always satisfy minimum require- 

55 ments for compatibility with the verifying module if 
any lower level of the module being verified satis- 
fies such compatibility requirements. Accordingly, it 
is preferred that the version identifier be an integer, 

3 
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and that compatible version field 107 contain an 
integer representing the minimum level required for 
satisfying compatibility requirements. If this is the 
case, compatibility can be verified by simply com- 
paring the two integer values, as shown at step 
203. However, it is not necessary to practicing this 
invention that integer values be used. For example, 
other ordered values such as a date or real number 
could be used. Nor is it essential that the value be 
ordered. For example, in an alternative embodi- 
ment, compatible version field 107 could comprise 
a list of compatible version identifiers. In another 
alternative embodiment, compatible) version field 
107 could comprise an integer value representing 
the minimum level required for satisfying compati- 
bility requirements as a general rule, together with 
a list of levels which are exceptions to the general 
rule. In these alternative embodiments, step 203 
would be appropriately modified to compare values 
from compatible version field 107 with the actual 
version identifier in order to verify that the module 
being checked meets minimum requirements for 
compatibility with the software module performing 
verification. 

Fig. 3 is an example of how this invention may 
be employed to verify compatibility of a plurality of 
interacting modules performing different functions 
within a computer system. The system of this 
example comprises host 301, two concentrators 
302,303, three workstations 304-306, and two print- 
ers 307,308, configured as shown. The host, con- 
centrators, workstations and printers each comprise 
a programmable processor executing a respective 
software module 311-318 of the appropriate class. 
Each module 311-318 contains a component ver- 
sion table, the contents of which are shown beside 
the respective module. In this example, host mod- 
ule 31 1 requires that each concentrator module be 
at version level 2 or above, 
each workstation at verstofHevel 1 or above, and 
each printer at version level 1 or above. Concentra- 
tor 1 module 302 requires that the host be at or 
above level 7, and each attached workstation be at 
or above level 1. Concentrator 2 module 303 re- 
quires that the host be at or abovu level 5, and 
each attached workstation be at or above level 1 . In 
this example, the concentrator does not care what 
level software module is running in tne printer or in 
the other concentrator, and accordingly has no 
table entry for a printer or concentrator class mod- 
ule. Furthermore, a concentrator wouid only have to 
verify compatibility o; the workstations which attach 
to it, not necessarily all workstations. It should be 
noted that the two concentrators are themselves at 
different levels, yet tnere is no incompatibility with 
the host. Both are at or above level 2, satisfying 
minimum level requirements for the host; the host 
in turn satisfies mir.imum level requirements for 



compatibility with the two concentrators. In the ex- 
ample of Fig. 3, there is an incompatibility between 
the workstation modules. Workstation 1 module 
314 is at level 1 and requires other workstation 

5 modules to be at or above level 1, while work- 
station 2 module 315 is at level 2 and requires 
other workstation modules to be at or above level 
2. In this example, workstation 1 module 314 would 
conclude that all modules with which it must inter- 

w act meet minimum compatibility requirements, but 
workstation 2 module 315 would detect that module 
314 does not meet its minimum requirements for 
compatibility, and raise an appropriate error con- 
dition. 

J5 The present invention achieves complete com- 
patibility verification without generating unneces- 
sary error conditions. Referring again to the exam- 
ple of Fig. 3, the concentrators are both compatible 
with the host although they are at different levels. A 

20 compatibility verification system which required 
that all modules of a particular class be at the 
same level would generate an error in this situation, 
even though all compatibility requirements are in 
fact met. On the other hand, a one-sided compati- 

25 bility verification performed, e.g., by the host, 
would leave open the possibility that the host did 
not meet requirements of one of the other compo- 
nents. Suppose, for example, that a third con- 
centrator at level 4 were added to the system of 

30 Fig. 3. and that this concentrator required that the 
host module be at or above level 8. In this case, a 
host directed verification alone would not detect the 
incompatibility. Finally, each module will verify 
compatibility only of those modules with which it 

35 must interact. In the example of Fig. 3, workstation 
module 314 does not meet minimum requirements 
for compatibility with printer module 318, but print- 
er module 318 will not check this because printer 
308 is not attached to workstation 304, and the 

40 modules don't need to be compatible. A centrally 
directed verification might conclude that there is 
some incompatibility under these circumstances. 

An alternative simplified embodiment of this 
invention will now be described. This embodiment 

45 is a simplification of the preferred embodiment 
which is made possible by the fact that the inter- 
acting set of software modules contains only two 
modules. In this embodiment, the modules execute 
in a processor used to monitor power conditions in 

so a device which is part of a computer system. The 
device is a pluggable device which may be re- 
placed without altering the rest of the system, e.g., 
a disk drive. In addition, devices are sometimes 
added to the system. The system includes a plural- 

55 ity of such power monitoring processors in commu- 
nication with each other, one of which is also in 
communication with the system central processing 
unit. The first of the software modules is stored in a 
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permanent read-only memory coupled to the pro- 
cessor, while the second is stored in an electrically 
erasable memory coupled to the processor. From 
time to time the computer's operating system will 
download a new version of the second module, but 
it is unable to alter the first. As a result of a new 
version of the operating system, it is possible that 
the first module will no longer satisfy requirements 
for compatibility with the second. In addition, it is 
possible that a pluggable device will be replaced or 
added without an upgrade to the operating system, 
and consequently that the second module will no 
longer satisfy requirements for compatibility with 
the first. In this simplified embodiment, it is not 
necessary to maintain a component version table 
with entries for different modules, because only 
one other module need be checked. Therefore the 
minimum version level required to meet compatibil- 
ity requirements is hard-coded into the software 
module as a constant value, eliminating the need 
for instructions that look up the value from a table. 
Each module compares the version level of the 
other module with this hard-coded constant to ver- 
ify compatibility. If an incompatibility is detected, 
an appropriate message is sent to the operating 
system. The operating system may be able to cure 
the problem by downloading a different version of 
the second module; if not, appropriate action is 
taken to inhibit interaction between the two soft- 
ware modules. 

Although in the preferred embodiment, the sys- 
tem components being verified for compatibility are 
software modules, in an alternative embodiment 
this invention can be used to verify compatibility of 
hardware components or components that are 
combinations of hardware and software. For exam- 
ple, electronic circuit cards in a computer system 
are also subject to frequent revision for the same 
reasons that software modules are. In accordance 
with this alternative embodiment, a circuit card 
comprises a programmable processor executing a 
software module. A permanent version identifier is 
associated with the combination of the card and its 
software. The card verifies compatibility with inter- 
acting circuit cards as described above for software 
modules. 

Although a specific embodiment of the inven- 
tion has been disclosed along with certain alter- 
natives, it will be recognized by those skilled in the 
art that additional variations in form and detail may 
be made within the scope of the following claims. 

Claims 

1. A method for verifying that a plurality of sys- 
tem components executing on a computer sys- 
tem are compatible with each other, wherein a 
component version is associated with each of 



said plurality of components, and wherein each 
of said components is associated with a com- 
ponent version identifier identifying the compo- 
nent version of said component, said method 
s being characterized in that it comprises the 

steps of: 

- obtaining the component version iden- 
tifier (102) associated with a first (101) of 
said plurality of components; 

- determining whether the component ver- 
sion identified by said component ver- 
sion identifier (102) associated with said 
first module satisfies requirements for 
compatibility with a second of said plural- 
's ity of components; 

- obtaining the component version iden- 
tifier associated with said second of said 
plurality of components; and 

- determining whether the component ver- 
20 sion identified by said component ver- 
sion identifier associated with said sec- 
ond component satisfies requirements for 
compatibility with said first (101) of said 
plurality of components. 

25 

2. The method for verifying compatibility accord- 
ing to claim 1 , characterized in that each com- 
ponent version identifier (102) associated with 
a component (101) is stored in a fixed exter- 

30 nally accessible location within the respective 

component (101). 

3. The method for verifying compatibility accord- 
ing to claim 1, characterized in that each said 

as component (101) is a software module. 

4. The method for verifying compatibility accord- 
ing to claim 3, characterized in that said step 
of determining whether the component version 

40 identified by said component version identifier 

(102) associated with said first component 
(101) satisfies requirements for compatibility 
with a second component comprises the steps 
of: (a) accessing compatible component ver- 

45 sion identifier information in said second com- 

ponent, and (b) comparing said component 
version identifier (102) associated with said 
first component (101) with said compatible 
component version identifier information in said 

50 second component; and said step of determin- 

ing whether the component version identified 
by said component version identifier associ- 
ated with said second component satisfies re- 
quirements for compatibility with said first 

55 component (101) comprises the steps of: (a) 

accessing compatible component version iden- 
tifier information in said first component (101), 
and (b) comparing said component version 
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identifier associated with said second compo- 
nent with said compatible component version 
identifier information in said first component 
(101). 

5 

5. The method for verifying compatibility accord- 
ing to claim 4, characterized in that each com- 
ponent version identifier associated with a 
component is stored in a fixed externally ac- 
cessible location within the respective compo- w 
nent. 

6. The method for verifying compatibility of claim 
4, characterized in that said compatible com- 
ponent version identifier information in said js 
first and second components comprises in 
each of said components a tab'e (104) of com- 
patible component version identifier values. 

7. The method for verifying compatibility of claim 20 
4, characterized in that said component version 
identifier associated with each of said first and 
second components comprises an ordered val- 
ue representing a component version level of 

the respective component; 25 
said compatible component version identifier 
information contained in each of said first and 
second components comprises an ordered val- 
ue representing a minimum compatible com- 
ponent version level; said step of comparing 30 
said component version identifier associated 
with said first component (101) with said com- 
patible version identifier information contained 
in said second component comprises compar- 
ing said ordered value representing the com- 35 
ponent version level of said first component 
(101) with said ordered value representing a 
minimum compatible component version level 
in said second component and determining 
that said first component satisfies requirements 40 
for compatibility with said second component if 
said ordered value representing the component 
version level of said first component is greater 
than or equal to said ordered value represent- 
ing a minimum compatible component version 45 
level in said second component; and said step 
of comparing said component version identifier 
associated with said second component with 
said compatible version identifier (102) infor- 
mation contained in said first component (101) so 
comprises comparing said O'dered value re- 
presenting the component ve» sion level of said 
second component with said ordered value re- 
presenting a minimum compatible component 
version level in said first component and deter- 55 
mining that said second cor i ponent satisfies 
requirements for compatibility with said first 
component if said ordered vaiue representing 



the component version level of said second 
component is greater than or equal to said 
ordered value representing a minimum com- 
patible component version level in said first 
component. 

8. A first system component of a plurality of 
interacting components of a computer system, 
wherein a component version is associated 
with each of said plurality of interacting com- 
ponents, said first system component being 
characterized by : 

- identifier fetching means for obtaining the 
component version identifier associated 
with a second component of said plural- 
ity of interacting components; 

- means for accessing compatible compo- 
nent version identifier information for said 
first component (101); 

- comparing means for comparing said 
component version identifier obtained by 
said identifier fetching means with said 
compatible component version identifier 
information to determine whether the 
component version identified by said 
component version identifier satisfies re- 
quirements for compatibility with said 
first component (101). 

9. The first system component according to claim 
8, characterized in that said component version 
identifier (102) associated with said first com- 
ponent (101) is stored in a fixed location within 
said first component accessible to means for 
accessing said component version identifier 
contained in said second component. 

10. The first system component according to claim 
8, characterized in that said component is a 
software module. 

11. The first system component according to claim 
8, characterized in that each said component 
version identifier associated with a component 
comprises an ordered value representing a 
component version level of the respective 
module; said compatible component version 
identifier information associated with said first 
component (101) comprises an ordered value 
representing a minimum compatible compo- 
nent version level; and said comparing means 
compares said ordered value representing the 
component version level with said ordered val- 
ue representing a minimum compatible com- 
ponent version level in said first component 
(101) and determines that said component ver- 
sion satisfies requirements for compatibility 
with said first component if said ordered value 
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representing the component version level is 
greater than or equal to said ordered value 
representing a minimum compatible compo- 
nent version level in said first component. 

12. The first system component according to claim 
1 1 ( characterized in that said component ver- 
sion identifier (102) associated with said first 
component (101) is stored in a fixed location 
within said first component accessible to 
means for accessing said component version 
identifier 

contained in said second component. 

13. The first system component according to claim 
11, characterized in that said component is a 
software module. 

14. A computer system comprising: 

- at least one programmable processor 

■OH): 

- a plurality of interacting system compo- 
nents (101), 

wherein a respective component version 
identifier (102) is associated with each of 
said plurality of interacting components; 

- means for obtaining the component ver- 
sion identifier (102) associated with a first 
(101) of said plurality of components; 

- means for determining whether the com- 
ponent version identified by said compo- 
nent version identifier (102) associated 
with said first module satisfies require- 
ments for compatibility with a second of 
said plurality of components; 

- means for obtaining the component ver- 
sion identifier associated with said sec- 
ond of said plurality of components; and 

- means for determining whether the com- 
ponent version identified by said compo- 
nent versiorTTclentifier associated with 
said second component satisfies require- 
ments for compatibility with said first of 
said plurality of components. 

15. The computer system according to claim 14, 
characterized in that each component version 
identifier associated with a component is 
stored in a fixed externally accessible location 
within the respective component. 

16. The computer system according to claim 14, 
characterized in that each said interacting sys- 
tem component is a software module. 

17. The computer system according to claim 16, 
characterized in that : said means for deter- 
mining whether the component version iden- 



tified by said component version identifier as- 
sociated with said first component (101) satis- 
fies requirements for compatibility with a sec- 
ond component comprises: (a) means for ac- 
5 cessing compatible component version iden- 

tifier information in said second component, 
and (b) means for comparing said component 
version identifier associated with said first 
component (101) with said compatible compo- 
rt) nent version identifier information in said sec- 
ond component; and said means for determin- 
ing whether the component version identified 
by said component version identifier associ- 
ated with said second component satisfies re- 
15 quirements for compatibility with said first 
component comprises: (a) means for acces- 
sing compatible component version identifier 
information in said first component, and (b) 
means for comparing said component version 
20 identifier associated with said second compo- 
nent with said compatible component version 
identifier information in said first component. 

18. The computer system according to claim 17, 
25 characterized in that each component version 

identifier associated with a component is 
stored in a fixed externally accessible location 
within the respective component. 

30 19. The computer system according to claim 17, 
characterized in that said component version 
identifier associated with each of said first and 
second components comprises an ordered val- 
ue representing a component version level of 

35 the respective component; said compatible 
component version identifier information con- 
tained in each of said first and second compo- 
nents comprises an ordered value representing 
a minimum compatible component version lev- 

40 el; said means for comparing said component 
version identifier associated with said first 
component with said compatible version iden- 
tifier information contained in said second 
component compares said ordered value re- 

45 presenting the component version level of said 

first component (101) with said ordered value 
representing a minimum compatible compo- 
nent version level in said second component 
and determines that said first component 

so (101) satisfies requirements for compatibility 

with said second component if said ordered 
value representing the component version level 
of said first component is greater than or equal 
to said ordered value representing a minimum 

55 compatible component version level in said 

second component; and said means for com- 
paring said component version identifier asso- 
ciated with said second component with said 
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compatible version identifier (102) information 
contained in said first component compares 
said ordered value representing the component 
version level of said second component with 
said ordered value representing a minimum 5 
compatible component version level in said 
first component and determines that said sec- 
ond component satisfies requirements for com- 
patibility with said first component (101) if said 
ordered value representing the component ver- to 
sion level of said second component is greater 
than or equal to said ordered value represent- 
ing a minimum compatible com jonent version 
level in said first component. 
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© Apparatus and method for verifying compatibility of system components. 



© Each component (101) of a plurality of interact- 
ing system components is associated with a version 
identifier (102). The version identifier (102) is stored 
in a location accessible by the other components. 
Each component independently reads the version 
identifier of every other component with which it 
must interact, and compares this value to an inter- 
nally stored compatibility record (103) to determine 
whether the other component satisfies requirements 
for compatibility with the verifying component. Any 
component which detects an incompatibility signals 
an error to the system. In the preferred embodiment, 
the components are software modules, and the ver- 
sion identifier and compatibility record contain in- 
teger values. The compatibility record value repre- 
sents the minimum level required of the module 
being verified for compatibility with the verifying 
module. Compatibility verification is accomplished 
by comparing the actual level of the module being 
verified with the minimum level in the compatibility 
record. If the actual level is equal to or greater than 
the minimum level, the module being verified satis- 
fies compatibility requirements. 
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